整车配置是怎么来的？都是来自SO吗？
准备记录一下ECN工程变更在不同行业的应用，想起，由ECN引发的标题的这个问题（整车配置是怎么设计的？都是来自SO吗？）在以前刚接触汽车行业解决方案时就很想完完整整地弄明白，因为这才是Auto - 可配置才能支持客制化（甚至所有配置项全开放给客户）、工程变更才能支撑汽车设计变革（一天一变，甚至一天多变）- “配置”只有结合“工程变更”才叫真正的Auto。
当然想真正“完完整整”，这几乎是不可能的，毕竟专业不同。以下仅就自己在过去项目实施，特别是类似作为“内部顾问”的陪产过程中，所做的记录。
（1）整车配置是怎么来的？
汽车是一个非常典型的可配置“模块化”组装的产品。
例如现在我们描述一辆车都是说：这是什么品牌（Audi）什么型号哪一款（A6L 40 TFSI 豪华致雅型）什么颜色（黑色）。知道了这个信息，车企包括消费者就知道了它代表着真正的车的含义：
发动机：140kW (2.0L涡轮增压)
变速箱：7挡双离合
长×宽×高(mm)：5038×1886×1475
前悬挂类型：五连杆式独立悬挂
主驾驶座安全气囊：有
电动天窗：有
全景天窗：无
运动外观套件：无
.....
然后也就很容易区分这一款与另一款（A6L 40 TFSI 豪华动感型）的异同，比如所有的特点都具有，其中发动机、变速箱等都一样，但是它的一些特点比如：
运动外观套件：有
....
上面的这些“含义”、“特点”，有时称之为Feature，在SAP里我们将其定义为“特征”Characteristics，比如上面的“发动机”、“变速箱”等；而所有的这些Feature组成一个包，有时称之为簇，在SAP里我们将其定义为“类”Class，比如上面的“Audi A6L”。
特征、类，它们的定义或设计，这是由专业的整车设计研发部门团队负责，一辆车大大小小的特征多达几十项。
从这种定义方式也可以看出，所有的特征组合才能唯一地决定一辆“明确的车”，但是，理论上来说，这就是一个数学上的排列组合问题，如下面这个图很形象地进行说明：
这在现实生活中，几乎是不可能的事情，因为在实际过程中，存在很多的“互斥”及“相互依存”的关系。
所以，首先，多达几十上百种的特征不可能全部都直接面向客户随意组合，必须解决“可操作性”；
其次，特征与特征间的关系必须使用一个载体进行自动推导，以防出现配置组合错误。
所以，在实际业务中，我们的对策是：
不会“显式”地开放所有的特征供用户直接选择，而是使用一种“配置组合包”的方式，来组合“我们可以提供给用户选择的空间”，比如，我们会放出“基本车型”Model、“内饰”Interior、“外观”Exterior、“可选包”Sales Package，也就是说，真实的几十上百种“特征”全部由这4大配置进行推导出来，更就是说，用户只需要在这4个“虚拟”的“特征”上进行组合，就可以决定了用户想要的“发动机”、“真批座椅”等等。这样一来解决前端选择可能出现的紊乱，更解决整车设计研发的清晰与可控，就好比数据库设计时的关键字段与其他字段；所以可以看成，这4大配置才是主特征。
会定义“对象相关性”Object Dependency（OD）。由它作为载体，将4大配置的组合，自动推导出其他真实特征，同时在这个推导过程中，就自动或采用或规避特征与特征间的关系。例如上面的例子，相关性的含义就是说：如果“基本车型“是“40 TFSI”，则“发动机型号”= “140kW (2.0L涡轮增压)”。
然后，可能会想，那为何就是那4大配置（基本车型、内、外饰、选装包）被“抽象”代表着车呢？
这其实就是“业务”。
从技术理论上来看，就像数据库设计一样，何不只设计一个“关键字”，然后其他特征全部都是“非关键字”，这里干嘛非将那4个字段（4大配置）虚拟成“关键字”。是的，技术是这样，但现实不是这样。
现实是：我有钱，我可以多加几个选装项，我没钱我就只要基本车型；我中规中矩，外观我就要黑白银，我有个性，我就偏要外观是紫色...
难道乎，让设计研发部门再将这4大配置做个排列组合？然后每推出一款选装包，都重新生成一下配置组合？显然不可能的。
当然在实际过程中，我们也曾经发现有一些特征真地不在这4大配置原始的推导关系中，那如何处理？2种方案：
将这个特征被囊括在某一个“主特征”的OD中，比如新建一个“选装包”，甚至“基本车型”。当然现实生活中，我们一般选择的是“选装包”。
将这个特征增加成“主特征”。当然现实生活中，我们一般不这么做。
这个设计完成之后，那这4大配置是如何决定相互作用，从而推导出整车的其他完整特征呢？
首先我们当然会在不同的主配置的OD里会有不一样的特征推导，例如“基本车型”的OD里是推导主要的如发动机、变速箱等特征，而选装包一般推导的是如真皮座椅、全景天窗等特征（当然可以随需要进行定义）；
然后，我们会在整车的OD进行组合起来，这样所有的特征就都可以由主特征的OD进行推导；
但是在组合过程中，我们会将主特征的OD进行排序，这是因为，比如“基本车型”决定了一个特征，但“选装包”可能修改这个特征，比如“基本车型”里“全景天窗”都是“否”，而“选装包”里选了“有全景天窗”。
这在SAP里如下：
每一行就代表着一种“主特征”，例如A1LK0100就代表着选择了这一个value的“基本车型”，前面的“排序”就代表着不同的配置的顺序。
所以，可以看到，当这些配置、特征、OD等都设计完成后，用户就可以在下单（销售订单，或CIR）中进行选择 4大配置，从而得到真正一辆车的属性。
（2）整车配置都是来自SO，与SO真地都一样吗？
从上面可以看出来，以前也有记录，使用了可配置物料的这种整车解决方案，整车一般来说，都是MTO的方案。
所以，作为需求源头，SO（也代指Customer Independent Requirement）决定了整车的配置。
所以，理论上来说，整车的配置全部来源于SO。也就是说，整车后续的其他单据，例如生产计划跑出的 整车计划订单，都将与这个SO里的配置是一样的。
这是理论，一般情况下的确是的。特别是计划订单Planned order与SO的配置都是一样的，因为从SAP的技术上来说，“配置”是由一个ID进行组合（CUOBJ），而计划订单的CUOBJ其实就是等于SO的CUOBJ。
所以，这也是为什么SO的配置一发生变化，PL的配置也就发生变化，也是为什么在实际销售生产过程中，我们需要管控设计研发不要动到现有的计划。
但有一个例外，那就是，我们的OD即对象相关性也会“动态地”修改到配置，例如，修改了“主特征”的OD,从而导致某些特征值修改了，而原始的SO并没有修改。
这会导致实际的问题，会导致SO里看到的配置与PL的配置不相同。
这种情况下，在真实的生产过程中，也的确会存在。
但是很不幸，当OD发生变化导致配置变更时，SAP并不会自动地去刷新SO从而也刷新计划订单PL的配置。
这种情况，就只能手动地或程序地方式进行刷新以补救生产计、以及生产现场上用的计划订单的配置。
以下聊表记录。